Skip to content

local echo (4.5/n): Prep for creating outbox messages on send #1509

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
May 13, 2025

Conversation

PIG208
Copy link
Member

@PIG208 PIG208 commented May 10, 2025

This prepares for #1472, toward #1441.

Requested by @chrisbobbe here.

@PIG208 PIG208 requested a review from gnprice May 10, 2025 02:24
@PIG208 PIG208 added the integration review Added by maintainers when PR may be ready for integration label May 10, 2025
Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, and thanks @chrisbobbe for the previous reviews! Generally this looks good; a few comments.

return this;
}

if (_value == kNoTopicTopic || _value.isEmpty) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "(no topic)" case here looks like it started more recently than the other, at FL 370:
https://zulip.com/api/changelog

Comment on lines 619 to 620
/// This assumes that the topic is originally for a send-message
/// request — such a topic must be constructed from a string without
/// leading/trailing whitespace.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, is that a requirement of the server endpoint? I don't see it here:
https://zulip.com/api/send-message#parameter-topic

Fine for this method to have this requirement; just shouldn't attribute it to the server.

Comment on lines 174 to 175
check(() => doCheck(eg.t(''), eg.t(''), 333))
.throws<void>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The throws here would end up catching an error from the check itself failing. That doesn't seem intended — I gather what you want is to check that interpretAsServer itself throws.

So for example this test as written still passes if you change this 333 to 334, at which point interpretAsServer doesn't throw but just returns an answer different from eg.t('').

/// `store.realmEmptyTopicDisplayName`.
///
/// See also: https://zulip.com/api/send-message#parameter-topic
TopicName interpretAsServer({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This name doesn't feel right to me — "interpret as server" sounds like it's trying to interpret the topic name as being a server (whatever that would mean).

How about processLikeServer?

Comment on lines 663 to 677
editTimestamp: editTimestamp ?? 1234567890, // TODO generate timestamp
editTimestamp: editTimestamp ?? utcTimestamp(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I commented on this change earlier today over on #1498 where Chris had cherry-picked it:
#1498 (comment)

@PIG208 PIG208 force-pushed the pr-echo-4.5 branch 2 times, most recently from 5296d17 to 815fff7 Compare May 12, 2025 23:40
@PIG208
Copy link
Member Author

PIG208 commented May 12, 2025

Thanks! Updated the PR.

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the revision! The code now all looks good, modulo rebasing atop #1365.

Comment on lines 619 to 620
/// This assumes that the topic is constructed from a string without
/// leading/trailing whitespace.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// This assumes that the topic is constructed from a string without
/// leading/trailing whitespace.
/// This returns the [TopicName] the server would be predicted to include
/// in a message object resulting from sending to this [TopicName]
/// in a [sendMessage] request.
///
/// This [TopicName] is required to have no leading or trailing whitespace.

The other part is needed too (I think it came from a comment @chrisbobbe made on the original PR): it says how this topic relates to the hypothetical scenario where the returned topic appears in a message object from the server.

return TopicName(kNoTopicTopic);
}

// TODO(#1250): This assumes that the 'empty_topic_name' client capability
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to update now that #1365 is merged; the doc above, too

PIG208 added 4 commits May 13, 2025 16:50
The point of this helper is to replicate what a topic sent from the
client will become, after being processed by the server.

This important when trying to create a local copy of a stream message,
whose topic can get translated when it's delivered by the server.
This will be the same as `DateTime.timestamp()` in live code (therefore
the NFC). For testing, utcNow uses a clock instance that can be controlled
by FakeAsync.

We could have made call sites of `DateTime.now()` use it too, but
those for now don't need it for testing.
@PIG208
Copy link
Member Author

PIG208 commented May 13, 2025

Updated this. Thanks!

@gnprice
Copy link
Member

gnprice commented May 13, 2025

Thanks! Looks good; merging.

@gnprice gnprice merged commit 0c03009 into zulip:main May 13, 2025
1 check passed
@PIG208 PIG208 deleted the pr-echo-4.5 branch May 13, 2025 23:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integration review Added by maintainers when PR may be ready for integration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants